One major advantage of Wide-Area Networks (WANs) and Local Area Networks (LANs) is the ability to utilize computer resources effectively. To achieve this goal, storage-intensive and computation-intensive functions can be relegated to remote networked computer systems that are optimized for carrying out these functions, allowing local networked client systems to require only minimal resources for storage and processing. The growing use of networking and, in particular, the ubiquity of access tools and utilities such as Internet browsers make it feasible to take advantage of centralized resources on server systems, while minimizing the requirements imposed on client systems. For example, devices such as “thin clients” can, by virtue of network connection, offer access to a broad range of applications run on a remote server. However, the thin clients themselves do not require more than a minimum of memory capacity or computing power.
Image processing is one type of document processing application that can take advantage of this type of remote processing capability. It is recognized that the storage, manipulation, and printing of digitized images can require considerable data processing and storage resources, for example. Complex tasks and applications can tax the resources of a standard desktop computer, requiring instead the speed and resources of a high-end workstation.
It is well known that when images can be uploaded, stored, and processed on a server system, benefits of lower cost, faster speed, and advanced capabilities can be more easily obtained. Currently, a number of commercial systems take advantage of the benefits of network utilization for imaging applications. Examples of such systems include services for uploading and printing of scanned photographs and digital camera images, such as the PhotoNet™ Online network from PictureVision, Herndon, Va., or the OnLine PhotoCenter™ from Konica Photo Imaging, Inc., Mahwah, N.J.
A remote server may be used for running some part or all parts of a document processing application, in conjunction with a client station. For example, U.S. Pat. No. 6,201,611 B1 to Carter et al. discloses a remote server that provides print processing functions. An application that runs on a thin client requests print processing functions from the remote server and provides the input file to be processed and processing parameters as part of this request. In existing prior art systems such as disclosed in U.S. Pat. No. 6,201,611 B1 and generally depicted in FIG. 1, when an operator running an application 18 on a thin client 16 requests a print job for a document, thin client 16 sends the complete document file over a network link 20 to a remote print server 10. The print request sent by thin client 16 includes the document data itself, with all text and images, in a Device-independent Format (DIF), along with print parameters and destination data for a locally connected target printer 24 or for an alternate network-connected target printer 22. A print rendering server 12 then executes an appropriate print driver for the target printer, processing the document file received from the thin client and generating a print data stream in Print-Ready Format (PRF). This data stream goes to a print router 14 on the remote server, which then forwards the PRF data to a print receiver 26 on thin client 16 and from there to locally connected target printer 24. Optionally, the PRF data can go directly to alternate network-connected target printer 22, if printer 22 has a built-in print server 26.
Although the system and method described in U.S. Pat. No. 6,201,611 B1 presents some advantages for more efficient processing of print files when using a thin client, it has a number of significant drawbacks. It is significant to note that in such a prior art system, only the print processing and driver functions are handled by the remote server. The thin client itself runs the balance of the document-processing application. Thus, the thin client generally requires more than a nominal amount of local storage and processing capabilities. Such an arrangement effectively defeats the purpose of the thin client as a major benefit obtained with a thin client is that the thin client device can have minimal storage and processing capabilities, thus minimal cost. To boost speed and performance for such a system would require increasing storage and processing resources at the thin client, so that a workstation may be a more economical and efficient substitute for the thin client.
Another drawback of the prior art system described in U.S. Pat. No. 6,201,611 B1 is that the entire document file, which is resident on the thin client, must be transferred as the DIF file to the print rendering server in the print request. With text files, the DIF file may not be sizable, and thus would not stress system or network resources. However, if a document includes bitmapped, moderate- or high-resolution color images, the resulting DIF file transferred could be very large, resulting in delay of transfer or excessive loading of the network. As another shortcoming of such a system, the alternate network-connected target printer 22 at the client site would require a built-in or attached dedicated print receiver, such as an HTTP server, for example. While there are printers commercially available having built-in HTTP servers, such as the Xerox DocuColor® 12 Printer with Fiery® RIP, such printers are typically high-end devices. There would be advantages to being able to implement a remote printing arrangement using low-cost printer peripherals, where low-cost printers are controlled by the local client. Moreover, HTTP protocol itself, designed primarily for text and Web image transfer, is not optimized for transfer of jobs to a printer and would require additional interface software to support print transmission.
European Patent Application EP 0 999 494 A2 discloses a method for control of remote printers, and input and output devices in general, over the Internet. More specifically, the disclosure teaches that data stored remotely can be transmitted by a server to a printer using HTTP protocol. To initiate a printing operation, a client or “initiator” transmits a request to the server. The server then schedules processing for the job, placing the job in queue. When it is capable of processing the job, the server then converts the job data into proper form for the destination printer. The server may obtain the source data for the document to be printed from the client or from some storage source on the network.
While the method of EP 0 999 494 A2 provides some benefits, there are some inherent drawbacks. Printing operation is managed and controlled from a print server that may be some distance away from the client as well as some distance away from the printer itself. This method requires that a printer be directly connected to the network or connected through a server having an HTTP interface. As with the method disclosed in U.S. Pat. No. 6,201,611 B1, HTTP network protocol may be required for communication with the printer. However, there are more efficient protocols for driving a printer on a network, such as is provided by the LPR utility, for example.
Firewalls, routers, and proxy servers are widely used as one means for protecting local area networks from unauthorized access. One key function of the firewall and related devices is to restrict network interaction to a safe data protocol, such as HTTP. While this arrangement has advantages for data and network security, there are disadvantages for data transfer to output devices such as printers. Significantly, the HTTP firewall, router, or proxy server requires that data be packaged in compatible HTTP formats, which are not optimized for printer bit stream transfer. As a result, some additional mechanism is required in order to pass PRF data from a local network to a remote site through a firewall.
The disclosure of EP 0 999 494 A2 shows the conventional approach used for obtaining networked printing through a firewall or similar device. However, as was noted above, the requirement that each printer provide an HTTP server restricts remote printing to networked printers only. Similarly, U.S. Pat. No. 6,201,611 B1 does not suggest a solution for thin client-to-server communication across a firewall or router, possibly requiring some additional well-known interface between the remote server and each networked printer. Such a solution would be costly, restrictive, and time-consuming to implement.
Computer operating systems, such as Unix® and Microsoft® Windows, for example, each provide some utilities for networked printing. However, conventional operating system printer utilities are intended for local area networks rather than for wide area networks. Current operating systems do not provide methods that allow networked printing over a firewall, router, or proxy server.
The recent Internet Printing Protocol (IPP) initiative addresses some of the problems associated with using printer devices that are, relative to a remote server, protected behind a firewall, router, or proxy server. However, IPP is a protocol for server and client device communication only, without any facility provided for operator interaction. Sending a print job to a printer using IPP requires that the server be provided with the IP address or other address of the target printer.
Thus, it can be seen that while there are networked print server solutions available that allow the use of thin clients and browser-based software to minimize some of the requirements for client resources in document processing systems, there is a need for a networked print server configuration that optimizes the advantages of server processing power, Internet network interaction utilities, and printer interface software and that is specifically designed for robustness and capability over a local area network as well as the capability to transfer printer-ready files over a firewall.
Accordingly, there is disclosed a remote print server that serves any number of remotely connected clients, accepting as input a print request and providing as output a data stream in a print-ready format. In addition there is disclosed a method of printing that allows control, from the client system, of a printer using conventional print utilities that are optimized for local printer control for printing a document residing on a network server. The method disclosed herein further allows any computer platform that is capable of running a browser to access the processing capabilities of a remote print server. Moreover, there is disclosed a method for printing a document residing on a networked application server at a printer controlled by a local client that permits transfer of a printer-ready bit stream across a firewall, router, or proxy server.
In accordance with the teachings herein there is disclosed a method for printing a document residing on a networked application server at a printer controlled by a local client. In one embodiment, the method comprises sending a print executable request from the local client to the networked application server; executing a print proxy executable at the local client, the executing including obtaining a print processing parameter; transferring to the networked application server, as a print specification command, the print processing parameter; and receiving, at the print proxy executable, a printer-dependent data stream conditioned by the print processing parameters in the print specification command, the printer-dependent data stream being rendered at the networked application server.
There is further disclosed a method for printing a document residing on a networked application server at a printer controlled by a local client comprising receiving at the networked application server a print executable request from the local client; receiving at the networked application server a print processing parameter from the a print proxy executable residing on the client; rendering a document at the networked application server in accordance with the print processing parameter to provide a printer-dependent data stream; and transferring, from the networked application server to said print proxy executable, the printer-dependent data stream, wherein the print proxy executable causes the printer-dependent data stream to be transferred to a printer controlled by the local client.
In accordance with the teachings herein, there is provided a method for printing a document at a printer controlled by a local client, wherein the document is stored and modified in a document file that resides on a networked remote application server. The method can be implemented on a broad range of computer platforms and operating systems. The method includes: (a) sending a print executable request from a browser on the local client to the networked application server; (b) in response to said print executable request, transferring, from the networked application server to the browser on the local client, a print proxy executable; (c) executing said print proxy executable at the local client in order to obtain print processing parameters; (d) transferring, as a print specification command, said print processing parameters obtained from said print proxy executable to the networked application server; (e) rendering the document at the networked application server to provide a printer-dependent data stream conditioned by said print processing parameters in said print specification command; (f) transferring, from the networked application server to said print proxy executable, said printer-dependent data stream.